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Expanded FileMaker Lookups: Overwrites & Aliases 


By Joe Kroeger 


FileMaker lookups have always been a pro¬ 
ductive and powerful feature and in FileMaker 
Pro 2.0 they have been improved further. The 
lookup definition has an added option and look¬ 
ups can now take advantage of System 7 aliases. 


Copying Empty Lookup Data 

Figure 1 (on page 2) shows the new Pro 2.0 
lookup definition dialog. In the lower right quad¬ 
rant there is a new checkbox option that tackles 
the issue of clearing a field in the destination data¬ 
base when the corresponding field in the lookup 


The FileMaker Report, issue 42, page 1, provided a 
detailed guide to FileMaker lookups. In issue 39, 
page 14, it was noted that Pro 1.0 requires that the 
lookup table be in the same folder as the destination 
file for automatic lookups. 


file is empty. In previous versions of FileMaker 
there was no option: an empty field in the lookup 
file would always leave the corresponding field in 
the destination file unchanged. Thus old data in a 
destination field was not overwritten by a lookup 
from an empty lookup field. Various workarounds 
were used to bypass this constraint - but they are 
not needed now in Pro 2.0. This new option is a 
good feature and adds another flexibile tool to 
our design kit. But be careful of surprises in your 
converted files. 

The new checkbox is labelled “Don’t copy 
contents if empty”. Until you get used to it, this 
can be misunderstood. Translate the label like 
this: “If the located data field in the lookup file is 
empty, do not copy the empty value into the des¬ 
tination data field when this box is checked.” If 
you want to operate the old way, you should make 
sure the box is checked. Be aware that Pro 2.0 
does not check the box when creating a new look¬ 
up. In addition, when converting a file from Pro 
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Lookup Ualue for Field “City” 


Lookup File 
“1.0 Zip Lkup” 


Copy the contents of: 
City ▼! 


...when the ualue in: 
Zip 


If no exact match, then - 
® don't copy 
O copy next lower ualue 
O copy next higher ualue 
O use 


1.0, Pro 2.0 does not 
check the box. Thus, 
converted files with 
lookups will not act in 
quite the same way as 
they did before until you 
change the new check 
box. This will usually be 
a minor point, but if 
some aspect of your 
design depends on not 
blanking out old entries 
in the destination file, 
you may get a little sur¬ 
prise with converted 
files. It makes sense to 

go through all lookup definitions to make sure 
that this new checkbox is set the way you want it. 

Aliasing 

When Apple first announced that there would 
be a file alias capability as part of System 7,1 con¬ 
sidered it interesting but of lim¬ 
ited usefulness. Now that I have 
finally migrated from System 
6.0.7 to System 7.1, however, I 
am finding several productive 
ways to take advantage of alias¬ 
es. A file alias is an added small 
file that acts as a pointer to the 
original file. When an alias is 
opened it is really the original 
file that is opened by the Sys¬ 
tem. An alias can also be 
created for folders and 
even for shared volumes. 

To help us know which 
files are aliases, the icon 
name is in italics. In a 
Windows environment 
there is no direct analog to 
the Mac alias capability as 
far as I know. 


Current File 
“Rlias Lkup Test” 


...into the field: 
“City” 


.matches a new entry in: 
Zip ▼! 


□ Don't copy contents if empty 
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Figure 3 


There are several situations where using an 
alias of a FileMaker lookup file can be helpful. If 
you have a master file of names and addresses of 
prospects, for example, and you have several des¬ 
tination files located in different project folders 
(Figure 2), it is nice to be able to create aliases of 
the master Prospects file and use them as lookups 
in project folders (Figure 3). The project folders 
may be scattered widely and/or nested deeply. 

Once an alias is created in the folder with the 
original file, drag it to the destination folder. 

Change the alias name, if desired, and then define 
the lookup(s) in the project database to use the 
alias as the lookup table. When a lookup event is 
triggered in the project file, the alias opens the 
original and lookups proceed as usual. 

Of course, instead of using aliases it would be but that could be quite messy - aliases in this case 

possible to just put everything in one big folder, I are aids to folderizing and folders help promote 

neatness and organization. 

Or, of course, it would also 
be possible to just put a dupli¬ 
cate of the master file in each of 
the project folders. But keeping 
the copies and the master up to 
date could be nearly impossible, 
especially if the Prospects file is 
being updated (perhaps across 
the network) at the same time 
that work is being done on pro¬ 
ject databases. Plus it can easily 
consume a lot of disk space for 
all those duplicates. 

Since an alias acts as a 
pointer to the original file, one 
would think that the alias could 
be moved around freely with¬ 
out problems but that moving 
the original would break the 
link with the alias. Not so. Sys¬ 
tem 7 is clever enough to up¬ 
date the alias when the original 
is moved. Very neat indeed. 

The implication is that once a 
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Figure 4 











Figure 5 


set of folders has been arranged and the aliases 
and lookups defined - perhaps like those in Fig¬ 
ure 3 - any of the folders, even the one containing 
Prospects, may be moved freely without disturb¬ 
ing the alias linkages. 

Figure 4 (on page 3) shows the Get-Info box 
for an alias. A simple button click can locate the 
original file and open the folder window that con¬ 
tains the original. Note that the directory location 
of the original is indicated in text. If the original 
has been moved to another folder, this part of the 
info box will not be correct until a lookup has 
been performed or until the Locate button has 
been clicked. 

As another example, consider a ZIP Code 
lookup table that contains the City and State assoc¬ 
iated with all 43,000 codes. Such a lookup is pro¬ 
ductive for use with a wide range of U.S. address 
files, allowing entry of a ZIP Code and the conse¬ 
quent lookup of the proper City and State. It 
would be awkward to put all the different address 
files that use the ZIP lookup in one folder, so until 
now I have been making duplicate Zip Tables for 
use in each address folder. With 


file wherever it may be needed. See Figure 5. Each 
folder defines local lookups that use the local alias 
that in turn points to the originbal Zip Table. 

When defining a lookup in FileMaker Pro 2.0 
using an alias of the lookup table, an interesting 
characteristic is that Pro looks through the alias to 
the name of the original file and inserts that name 
into the lookup definition. If the original is called 
Zip Table and the alias is named (how clever) Zip 
Table alias and is used to define the lookup, you’ll 
notice in the lookup definition dialog that Zip 
Table appears instead of Zip Table alias. 

Anti-aliasing 

It may be that Pro 2.0 just uses information 
from the alias to define a direct link to the origi¬ 
nal. To test this hypothesis, I established a lookup 
link through an alias to a lookup table located in 
another folder. After verifying that the lookup 
worked properly, I deleted the alias and tried 
again. Guess what: the lookup still worked; File¬ 
Maker remembered where the original was even 
when the alias was absent. 

I then tried moving the 


the advent of Pro 2.01 can in¬ 
stead use an alias for the lookup 




original to the folder where the 
alias had been. The lookup con¬ 
tinued to work. Folder locations 
other than these two for the 
lookup file, however, did not 
work. When a FileMaker file 
attempts an aliased lookup, it 
evidently checks both the cur¬ 
rent folder and the folder point¬ 
ed to by the alias. 

The basic reason that File¬ 
Maker lookups needed an alias 
capability is that Pro 1.0 could 
not remember an established 
lookup link outside the current 
folder. (Such a link can be set 
up manually in Pro 1.0 when 
the file is first opened or when 
the first lookup is attempted. 
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The connection will then last only as long as the 
lookup file remains open.) 

But given the remembering capability evident 
in Pro 2.0,1 tried making a lookup connection to 
a distant lookup file without using an alias as an 
intermediary. Not only does it work, but the con¬ 
nection is maintained even if the lookup is closed 
and even if FileMaker is quit and reopened. It 
does not work if the lookup is moved (to any lo¬ 
cation other than the folder containing the desti¬ 
nation file), but it does work if the destination file 
(where the lookup is defined) is moved to anoth¬ 
er location. My conclusion: Pro 2.0 lookups are 
much improved even if you do not use aliases, 
but there are still contributions aliases can make. 

Remote Lookups 

There is another place where an alias can 
come in handy. When a remote file on the net¬ 
work is used as a lookup in a file-sharing environ¬ 
ment, an alias makes it easier to establish the link 
across the network. 

There are two ways that FileMaker can access 
a lookup file that resides on another machine on 
an AppleTalk network. With System 7 file sharing 
inactive, FileMaker uses the internal networking 
capability built into the program. The require¬ 
ments are that both FileMaker itself and the look¬ 
up file must be open on the remote machine and 
there must be an active AppleTalk network be¬ 
tween them. Then the lookup can be accessed on 
the local machine by clicking on the Network 
button in the Open File dialog. Once open, the 
remote lookup file acts like a local file and servic¬ 
es local destination files as they request lookups. 
(Network lookups like this are quite fast.) 

In this environment use of an alias is not pos¬ 
sible - there is no way to create one on the local 
machine: the lookup only exists locally as a win¬ 
dow within FileMaker. An alias of the lookup file 
created on the remote machine and then copied 
to the local machine does not work. 

The second way to access a remote lookup file 


is through System 7 file sharing. System 7 allows a 
remote folder or disk to be mounted on the desk¬ 
top of the local machine via an AppleTalk net¬ 
work. (Quite neat, although setting up file sharing 
is messy.) Once the remote folder or disk is 
mounted locally, the lookup file can be opened 
and used as if it was physically local. This means 
that an alias can be made, copied to the local disk, 
and then used as a lookup. If the file sharing con¬ 
nection has not been made, the lookup alias is 
smart enough to initiate the connection when 
opened (you'll still need to supply a password). 
Note another feature: it is not necessary for the 
FileMaker application (and therefore for the 
lookup file) to be open on the remote machine - 
it is opened by the local FileMaker application. 

Figure 6 shows a folder with an Alias Lkup 
Test destination file that is local to the JK 320 
hard disk. The PB 40M disk is a remote hard disk 
that has been mounted by System 7 on the local 
desktop. A lookup file called Zip Table R lives on 
the PB 40M disk. The Zip Table R Alias file is an 
alias created on PB 40M and then copied to the 
More Test folder on JK 320. As long as PB 40M is 
mounted, the alias works fine and FileMaker can 
be opened and closed freely. If Zip Table R is 
closed and a lookup is attempted, the remote 
lookup file is opened automatically. If PB 40M is 
unmounted and a lookup is attempted, you are 
prompted to locate the lookup and/or to enter a 
password to mount PB 40M. Nice. 

-V- 
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Figure 6 







Calculating Date Suffixes: Putting the “nd” in “2nd” 


By Keni Jones 

Two weeks after Hurricane Iniki devastated 
the island of Kauai, a roofing company hired me 
as a database consultant to track their Iniki roof 
repair jobs. Calls for repairs were flooding in at an 
overwhelming rate, and the company needed 
immediate use of a computerized database. Their 
new secretary had never used a Macintosh before, 
so ease-of-use was also a top priority. They need¬ 
ed a quick way to generate repair estimates and 
job proposals. The database became known as the 
Roofing Proposal Generator, and it allowed the 
roofing company to accelerate processing from 4 
or 5 proposals a day with a spreadsheet and word 
processor combination to over 30 a day using 
Filemaker alone. 

Background 

My client requested that the data entry pro¬ 
cess be automated as much as possible to avoid 
errors, so I made extensive use of text and num¬ 
ber calculations, as well as pre-defined value lists 
and lookups activated through pop-up lists. A 
companion lookup file provides material and 
labor prices, as well as many roofing procedural 
descriptions. The database now has 158 fields, 60 
of which are text and number calculations. (I am 
currently redesigning portions of it using some of 
the ideas in the “Project MIS” article from The 
FileMaker Report #34 to split out several of the 
functions into separate files for easier job tracking 
and management.) 

The Challenge 

Four layouts in the Proposal Generator data¬ 
base are set up as proposals. Since the proposals 
constitute legal contracts intended for signature 
by the homeowners, they necessarily include the 
date of the proposal. My client wanted the word¬ 


ing to read, for example, “This agreement is made 
on this 22nd day of September, 1992” The “nd” 
following the 22 is the date suffix, and it changes 
depending on the actual day of the month. The 
problem is to decode the correct suffix and ap¬ 
pend it to the numeric day. 

I originally defined a Date Suffix text field to 
pop-up the required four pre-defined suffix values: 
“st”, “nd”, “rd”, and “th”. The operator would 
select the appropriate value from the pop-up list 
after the date was entered. A few proposals were 
mailed with the wrong date suffix, so my client 
requested that I make the program automatically 
calculate the date suffixes. 

I consulted my back issues of The FileMaker 
Report for a handy tip on the best way to accom¬ 
plish this, but I found no references to it, so I was 
intrigued to invent a way that works well. 

Those Difficult Teens 

The problem involved grouping the dates that 
have common suffixes. The general rule is: 

• days ending in “1” should be followed by “st , 

• days ending in “2” should be followed by “nd , 

• days ending in “3” should be followed by rd , 

• all other days should be followed by “th”. 

There is, of course, an exception to the general 
rule: the “teen” numbers all require the “th” suf¬ 
fix. For 32 we say “thirty-second” but for 12 we 
do not say “tenty-second”; instead we use a single 
word: “twelveth”. Thus I had to extract specific 
date numbers to take care of the exceptions. 

The central problem was to have FileMaker 
perform a calculation that would extract the day 
numbers from the Proposal Date field (for exam¬ 
ple, 9/22/92), and then calculate the correct suffix 
following the day portion (22nd). My first formu¬ 
la calculated the suffix by extracting the day from 
the Proposal Date field itself using the Middle 
function, and then used the result with a series of 
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Figure 1 


nested “If’ statements to test for the right suffix 
from the four possible choices. However, it always 
returned the “th” suffix, because, as far as I can 
determine, the Middle function only works cor¬ 
rectly on Text fields. A preceding formula was 
necessary to convert the Proposal Date to a text 
result, like this: 

ProposalDateTxt = DateToText (Proposal Date) 

This calculation automatically converts a date 
like 1/3/93 to the text result 01/03/93, automati¬ 
cally inserting any missing leading zeros. 

Using this ProposalDateTxt field with the 
Middle and If functions, I arrived at an equation 
that works correctly every time: 

Date Suffix = If (Middle (ProposalDateTxt,4,2) = 
"01" or Middle (ProposalDateTxt,4,2) = "21 * 
or Middle (ProposalDateTxt,4,2) = "31", "st", 

If (Middle (ProposalDateTxt,4,2) = “02" or 
Middle (DateToText Calc,4,2) = "22", "nd", 

If (Middle (DateToText Calc,4,2) = "03" or 
Middle (DateToText Calc,4,2) = "23", "rd", "th"))) 

Note that the Middle function, as used here, 
extracts information from specified positions 
located by counting. It only works properly be¬ 


cause the DateToText function automatically 
‘normalizes’ the result by inserting appropriate 
leading zeros. Thus every date has 8 characters, 
allowing the Middle function to work. 

Then I discovered the Day (date) function. It 
simplified the calculation by retrieving the day 
number directly from the date, and allowed cor¬ 
rect calculation of the date suffix with nested If 
statements. Figure 1 shows the equation. 

I constructed the order of both these formulas 
to compare Proposal Date with 1, 21, & 31 first 
for a logical true result, because there are seven 
months of the year that have three dates each 
requiring “st”. Conversely, “nd” and “rd” are 
required only twice a month each. The more fre¬ 
quent occurrences of “st” will allow the formula 
to find a true result more often in the first com¬ 
parison and perhaps, therefore, be a little faster. 

I experimented with several other equations 
and managed to find some that are more cumber¬ 
some than Figure 1.1 tried using the logical not 
operator (not the “st”, “nd”, 8c “rd” dates). I 
constructed another formula that looks for a “th” 
date range: 

If (Day (Proposal Date) > 3 and Day (Proposal 
Date) < 21 or Day (Proposal Date) > 23 and Day 

(Proposal Date) < 31, 


Options for Field “Date Suffix Calc” 


0000® 
0000® 
0000 ® 
®0000 
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iliiii 
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If (Day (Proposal Date) = 1 or Day (Proposal Date) = 21 or Day 
(Proposal Date) = 31, "st", If (Day (Proposal Date) = 2 or Day 
(Proposal Date) = 22, "nd", If (Day (Proposal Date) = 3 or Day 
(Proposal Date) = 23, "rd”, “th"))) 


K> 
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Calculation result is Text 
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□ Repeating field with a maximum of \2 


ualues 


( Cancel ] 

ILgg—1 


"th" ..., 

(Any FileMaker Report 
readers with a better 
way to handle this, 
pleasae let me know.) 

Custom Date 
Formatting 

The next task was to 
format the fields to dis¬ 
play and print correctly. 
I inserted the Proposal 
Date field twice on the 
proposal layout. Using 
the Custom Date 
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Figure 3 Figure 2 
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October, 1991 
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Format feature (Figure 2), I formatted the first 
occurrence to display and print a two-digit day 
(as in “22”)> and the second occurrence to display 
and print only the month and year of the same 
date, separated by a comma and a space (as in 
“September, 1992”). 

To insure maximum accuracy in entering the 
proposal date, I created a non-printing button on 
the proposal layout that, when clicked, automati¬ 
cally pastes the current date into the Proposal 
Date fields. (The Define Button command in the 
Scripts menu accomplishes this.) It usually takes 
more than a day to inspect the roof and prepare 
the proposal, so Today needs to be entered man¬ 
ually when the actual proposal is being prepared 
rather than use an auto-entered date when the 
record is created. 


When the date 
is pasted into the 
“day” occurrence, 
it is formatted for 
the conventional 
MM/DD/YY. The 
field expands 
downward (Figure 
3) in a narrow, 
vertical rectangle 
covering the lines 
of text below, be¬ 
cause the field is 
sized to be only wide enough to contain two char¬ 
acters. It remains that way until you tab to the 
next field or click elsewhere, then the “day” dis¬ 
plays and prints as desired. 

Final Obsessive Tweaking 

I experimented with how tightly I could posi¬ 
tion the layout text and the adjacent date and date 
suffix fields so that the Browse view was not ob¬ 
jectionable to the aesthetics of the data processing 
people. I found that “nd” was the widest date 
suffix, and September the widest month name. 
The widest date number followed by “nd” was 22. 
As long as “...the 22nd day of September, 1992” 
fits and looks appropriate in Browse and Preview 
modes, the rest of the dates (including the short 
1st of May) will fit and look acceptable too. Fig¬ 
ure 3 shows the 
final results in Lay¬ 
out, Browse, and 
Preview modes. 

For more infor¬ 
mation on the 
Roofing Proposal 
Generator, contact 
Keni Jones, Keniki 
Software, PO Box 
771, Kapaa, Kauai, 
Hawaii 96746, 
(808)823-6871. 
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between XYZ Roofing Company, Inc. of Hawaii and 

John Doe concerning the Shake Roof located at 123 Coconut Street, 
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Calculating Fonts and Font Styles? 


By Joe Kroeger 

Is it possible to control font styles from with¬ 
in a calculation field? Example: when the value of 
a result meets a certain criterion, make the result 
bold, otherwise make it plain. Let's try. 

As a first attempt, I built an equation and 
tried to make two result alternatives different 
styles: 

Notice = 

If (PastDueAmt > 500, "ALERT", "NOTE") 

But I was not able to make word ALERT bold 
within the equation. This example does not work. 

If it was possible to specify as an additional 
parameter a direct style capability within an equa¬ 
tion, it might take a form like: 

Notice = {text result} 

If (PastDueAmt > 500, [Bold]"ALERT", 

[Plain] "NOTE") 

(The square brackets are just one possible 
mechanism to indicate to FileMaker that the style 
commands are not constants or names of fields.) 

But since we don’t have such additional para¬ 
meters available, is there a workaround? How 
about creating separate fields to hold the ALERT 
and NOTE words? We could then format them as 
desired and build an equation like this: 

Textl {text field, bold} 

Text2 {text field, plain} 

Notice = {text result} 

If (PastDueAmt > 500, Textl, Text2) 

The field Textl contains the word ALERT and 
the field is formatted as bold; the field Text2 con¬ 
tains the word NOTE and the field is formatted as 
plain. Sorry, no dice - the formatting in Textl 
does not flow through the calculation and into 


the Notice field. I also tried the same calculation 
with the Textl field formatted as plain and word 
itself formatted as bold. It still does not work. 

Looking Up in Style 

OK, time for another approach. How about if 
we try putting the two words - formatted as de¬ 
sired - into a simple lookup table. The the result 
of the calculation becomes a lookup key that then 
accesses the table. Can we look up a bold word? 

Notice {text field} 

Test = If (PastDueAmt > 500, A, B) {text result} 

Notice is now a field that will hold the looked- 
up value and Test is a calculation that generates 
the lookup key. The lookup table is quite simple, 
like the one shown in Figure 1. 

Ta-Da! It works! The only problem is to make 
sure that the lookup state of the Notice field re¬ 
flects the current state of the record. This means, 
for example, that a Relookup (based on Test) 
should be executed before attempting a Find or a 
Sort on Notice. These steps can be combined 
nicely into a script. 

Double Up 

One more approach seemed worth trying. I 
built two calculations that provided mutually- 
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exclusive results: 

Noticel = If (PastDueAmt > 500, "ALERT", "") 
Notice2 = If (PastDueAmt < 500, "NOTE", "") 

I formatted Noticel as bold and Notice2 as 
plain (Figure 2). Then I put the two fields right on 
top of each other (Figure 3). Since one of the two 
is always blank and the other always presents a 
word, the result in Browse is what we wanted. See 
Figures 4 and 5. 

These same approaches work when trying to 
select font differences or size differences. If there 
are several alternatives from which to choose, it 
will often be easier to use the lookup table. For 
just a few variations, the overlapping fields work 
well. In addition, the overlapping the fields mean 
you don’t need to pay special attention to issues 
of validity. 
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Problem Style 

A different style difficulty that is not so easy to 
work around are the new superscript and sub¬ 
script styles. Their addition to the FileMaker style 
list is welcome and helps solve some older prob¬ 
lems. But super- and sub-scripting do not survive 
a text calculation. The lookup solution works 
with super- and sub-scripting and with other 
styles and sizes as well. 

Wish List 

As a future capability for FileMaker, it would 
be nice if, in a text-result calculation, text format¬ 
ting of data in a field that is a parameter (not field 
formatting) would flow through the calculation 
and show up unmodified in the result. The com¬ 
plicating factor is that we would also need some 
way to turn off that flow-through when it is not 
wanted. 
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Viewing the Index of the Found Set 


By Mike Harris 

Very soon now, I will have been doing pro¬ 
fessional FileMaker consulting for a decade. Of all 
the lessons I’ve learned during these years while 
slouched over Mac keyboards, one stands out: be 
very careful when you think you’ve found some¬ 
thing FileMaker can’t do, because you are almost 
certainly wrong. Or, as I sometimes put it when 
speaking to user groups: if someone tells you it 
can’t be done in FileMaker, you are talking to the 
wrong person. 

This article describes a trick that illustrates this 
principle nicely. It also illustrates another point: 
tricks for doing ‘impossible’ feats are often dead 
simple. 

The problem has for years resided on the 
Wish List of The FileMaker Report. It was raised 
again at a meeting between consultants and Claris 
during San Francisco MacWorld in lanuary of 
1993. It was mentioned as a feature very much 
needed in future versions of FileMaker. All the 
attending Claris people and consultants, includ¬ 
ing myself, gravely agreed this should be part of 
FileMaker. It was solemnly added to a hand-writ- 
ten list (that presumably will wend its way to the 
FileMaker programming team). Based on this and 
checking with the editor of The FileMaker Report, 

I feel pretty sure that, as of February 1993, no one 
in the FileMaker community thought you could 
actually View Index of the Found Set (VIFS). 

(There are evidently sound reasons that it has 
not yet been included within the application. File¬ 
Maker functionality and performance are critical¬ 
ly dependent on the full-indexing backbone of the 
program.) 

The Problem 

FileMaker indexes every word (and date and 
number) in every field in every record. The View 


Index (aka Paste Special...From Index...) feature 
built into FileMaker is invaluable for examining 
values without finding, for finding with precision, 
for locating errors, and for getting a “sense” of the 
span of data in a field. For instance, it is easy in an 
address file to enter incorrect ZIP codes or errone¬ 
ous state abbreviations. A quick look at a field 
using View Index will show many types of bad 
ZIPs - there should be no letters and all numbers 
should be five dig¬ 
its, for instance - 
or bad state abbre¬ 
viations. You can 
also see if foreign 
ZIPs or country 
names have been 
misplaced into 
fields designated 
for US only data. 

You can even look 
at a street address 
field index and notice 
likely misspellings of street names - like 
“Wahsington” or “Linclon” (see Figure 1). 

There are times when it would be very useful 
to View Index on only the records in the found set. 
For instance, suppose you have a database of 
newsletter subscribers, including both active and 
inactive names. You might want to know whether 
the inactive names seem to have different sub¬ 
scription starting dates from the active subscrib¬ 
ers. View Index on the Found Set would allow 
you to quickly make this comparison and perhaps 
decide whether the comparison was worth further 
follow up through, say, exporting subscription 
start dates to a text file or graphing program. 

The Theory 

VIFS is not now possible using the original 
fields in a database - they will always have an 
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Figure 1 










Figure 2 


index reflecting all the records in the file. Another 
field is needed through which you can VIFS for 
the field of interest. In each record, this new field 
should contain the value in the “original” field 
only when the record is in the found set. So, this 
viewing field’s normal index will be the VIFS in¬ 
dex of the first field. How do we do this? 

If the original field you want to VIFS is the 
LastName field in an address file and Newlndex 
is the field for viewing the index of the found set 
and FoundSet is a field with a “0” or “1” number 
value, then: 

Newlndex = {text result} 

lf(FoundSet = "1", LastName, "") 


field for each field you want to index. These new 
fields can be associated with their parent fields in 
some helpful way. For instance, in the example of 
a VIFS field for LastName, we could place the 
Newlndex field precisely behind (underneath) 
the LastName field on a layout. Since during nor¬ 
mal mousing around Newlndex would not be 
accessible, this insures that the normal look and 
behavior of the layout is the same as before and 
the new field wouldn’t take up valuable layout 
real estate. Then you might turn the field label 
‘Last Name’ into a button, again just to save space. 
With the appropriate script (see below) associated 
with the ‘Last Name’ label, you get the following: 

When you want to VIFS the LastName field, 


first Find the group of records in which 
you are interested. In Figure 2 we are 
finding all names that start with ‘H’ 
through ‘J’. 

Then click on the ‘Last Name’ label 
(Figure 3). This triggers a script which 
enters a “1” in the FoundSet field, does 
a Replace in the found set of records 
and brings up View Index on the 
Newlndex field. See Figure 4. (Note 
that although the LastName field con¬ 
tains names that span the whole alpha¬ 
bet, Figure 4 shows only names in the 
H-J range, reflecting the found set.) 

When you place a “1” in FoundSet in all the When you are through looking at the index, 

records of the found set, the Newlndex field will | close the View Index box. The script then re¬ 
contain values only in records in the found set. If moves all the “l’s” from FoundSet and returns 

(Other records will have nothing in the Newlndex | you back to normal Browse mode, 

field.) So when you view the index of the New- This approach works well and is pretty much 

Index field, you’ll see only the LastName values transparent to the user. On a Quadra 700 with a 

that reside in the found set. I 



The Practice 

As promised, the basic trick is simple, as you 
can see from the calculation above. It is actually 
more complicated to design and implement the 
best way to use the trick in a real-world file. One 
approach is to create a version of the Newlndex 



Page 12 • Issue 49 • ©1993 Elk Horn Publishing • The FileMaker Report 


Figure 3 



















Figure 4 


ply use the Command - i short cut. 

(4) When finished viewing the index, put a “0” in 
the FoundSet field of the current record and se¬ 
lect Replace... from the Edit menu to put a “0” in 
each record of the found set. 

Step 4 insures that none of the current records 
will be mistakenly included in some future run of 
this procedure. 

To create a script to do the same steps auto¬ 
matically, select Scriptmaker under the Scripts 
menu and enter a name for the script. We will use 
View Index Found Set. After entering the script 
name, click on the Create button. Then: 

• Select “Go To Field”, select the “Select/Play” 
and “Field” check-boxes and then select the 
FoundSet field from the field list. 

• Select “Paste Literal”, click on the “Specify” 
button and enter the number “1”. 

• Select “Replace” and select the “Perform with¬ 
out dialog” and “Specify Field...” check-boxes and 
then select the FoundSet field from the field list. 

• Select “Go To Next Record /Request”. (This 
step is required to insure that all new field values 
are added to the field indexes; in FileMaker the 
index is not updated until you leave the current 
record or cause it to be entered; alternatively, 
choose “Enter Browse Mode” for this step which 


The manual steps for 
using the fields we have 
defined go like this: 

(1) Find a group of 
records. 

(2) Put a “1” in the 
FoundSet field of the 
current record and select 
Replace... from the Edit 
menu to put a “1” in all 
the records of the found 
set. 

(3) Click in the VFIS field 
and select Paste Special 

... From Index... from 
the Edit menu - or sim¬ 
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Go to Layout [.,.] 
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* Go to Field [Select/play, "FoundSet "] 


Go to Previous Record/Request jljl 

| * Paste Literal ("0"] 


Go to Field [...] 

* Replace [No dialog, "FoundSet"] 


Go to Next Field 



Go to Previous Field 
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found set of 100 records or so, the process is near¬ 
ly instantaneous. No additional layouts are re¬ 
quired and you can set up the VIFS trick only on 
those fields in which you are likely to have a VIFS 
interest. In most cases, this will be the best way to 
implement the VIFS trick. 


The Script 
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Figure 5 




























Figure 6 


accomplishes the same thing.) 

• Select “Paste from Index”, select the “Specify 
field” check-box and choose the field Newlndex. 

• Select “Go To Field”, select the “Select/Play” 
and “Field” check-boxes and then select the 
FoundSet field from the field list. 

• Select “Paste Literal”, click on the “Specify” 
button and enter the number “0”. 

• Select “Replace” and select the “Perform with¬ 
out dialog” and Specify Field...” check-boxes and 


then select the FoundSet field from the field list. 

See Figure 5 for the finished script. To associ¬ 
ate this script with the ‘Last Name’ field label, go 
to the appropriate layout and in Layout mode 
define the ‘Last Name’ field label as a button which 
executes the View Index Found Set script. 

Now you’re in business. Amaze your friends, 
startle your neighbors and watch envy ripple 
through your local user group. 


Another Way 

The main implementation of the VIFS trick 
may not work well for all files. You have to create 
a new VIFS field for each field you want to exam¬ 
ine and you might have to do a lot of tedious 
work to your existing layouts. You also end up 
calculating the contents of each VIFS field you 
have set up and each such new field uses memory. 
When only a few fields are involved, the first ap¬ 
proach works well, but there are other ways to 
implement the basic trick. The following method 
uses a single additional layout for all VIFS work 
and can be advantageous in a file with many fairly 


similar layouts. 

Again, you need to make the process of enter¬ 
ing and removing “l’s” from FoundSet automat¬ 
ic, both to eliminate drudgery and cut down on 
mistakes. This time, however, we don’t want one 
VIFS field for every original field in which we are 
interested, so we change the Newlndex formula 
to allow a choice of several fields for VIFS. (After 
all, we can only view index on one field at a time 
anyway.) Let’s do that first. 

Define a new field, VIFS Field, as a text field 
with a value list of the fields you want to VIFS. 
We will choose: 
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FirstName 

LastName 

Company 

City 

State 

Place VIFS Field in a new layout and format it 
as a radio button field (see Figure 6). Now the 
new Newlndex field formula is: 

New Index = {text result} 

If (FoundSet = 1 and VFIS Field = "FirstName", 
FirstName, If (FoundSet = 1 and VFIS Field = 
"LastName", LastName, If (FoundSet = 1 and 
VFIS Field = “Company", Company, If 
(FoundSet = 1 and VFIS Field = "City", City, If 
(FoundSet = 1 and VFIS Field = "State", 
State,""))))) 

You can now choose which field the index for 
Newlndex will reflect. This is done by selecting 
the name of the field you wish to VIFS in VIFS 
Field and doing a universal Replace into the 
found set. A quick look a the Newlndex formula 


above should show that Newlndex will now have 
an index which is the VIFS of the field chosen in 
VIFS Field. Figure 6 shows a rough layout dedi¬ 
cated to VIFS in which the FirstName field has 
been chosen as the field to view in Newlndex. 

-V* 


Mike Harris is Senior Partner at Watertechnics, 
a Macintosh business systems consultancy which 
specializes in FileMaker databases for small busi¬ 
nesses and corporate workgroups. Watertechnics 
also publishes FileMaker templates including award 
winners CrimeBuster and Main Events. Mike is a 
frequent contributor to the FileMaker Report and 
author of several bestselling Application Notes car¬ 
ried by the Elk Horn Library. He may be reached at 
408-761-3987, fax 408-761-5468 or AppleLink 
X2338. A small demo file of the formulas and scripts 
used in this article is available to subscribers from 
Watertechnics for a charge of $10 US. 


Wrong Telephone Number 

We moved. In the last issue we published a 
new phone number for Elk Horn Publishing. 
Unfortunately it turned out to be the wrong num¬ 
ber (unless, that is, you wanted a way to not get 
hold of us). Please ignore past references to a 
‘700’ number and delete it from your records and 
your mind. 


Here is a proper new number: 

408 - 726-1232 

Please add it to your records and pass it along 
to others who would like to know - your purchas¬ 
ing department, for example. Our mail address 
remains as shown on page 16. You should remove 
other old address you may have for us. 
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